USING EVENT-BASED TRANSLATION TO SUPPORT DYNAMIC PROTOCOL EVOLUTION by NATHAN

server-side coordination, depicted by Figure 16 on page 47. 193 The server begins by connecting to the negotiator and registering the address (host and port number) of its handler as implementing a role used by one or more protocols. The server can register as many handlers/roles as desired. Note that the specification for protocols that utilize these roles need not be present in the data directory of the negotiator. The handler of the server then waits for a connection to be established. The server-side negotiator does likewise. When the negotiator does accept a connection, it first receives a request for a role-specific port of a translator for a particular protocol. Checking its register, the negotiator determines if any server components have listed themselves as implementing the role in question. If not, an error code is returned to the remote, client-side negotiator. If a corresponding server component is instead determined, a translator for the protocol is generated. The translator returns its application-side port to the negotiator via the input/output stream. Once the translator has been generated and the appropriate port received by the negotiator, the negotiator contacts the new translator at the address and requests that a server socket be created for the role in question. The port of the server’s handler is provided as the role’s implementer. The translator creates the socket, which is now listening for incoming (protocol) messages. The address of the socket is returned to the negotiator, which forwards it to the client-side negotiator. Now, the handler of the server, the server-side negotiator, and the server-side translator are all waiting for connections. (In the case of the negotiator, it is waiting for another connection, in reference to another interaction). 194 When the server-side translator accepts a connection at the server socket (specific to the role in question), it connects the input stream of the new connection to a parser. The output of the parser is connected to the handler (listening at the address associated with the server socket, provided by the negotiator), and parsing commences. Generated events are sent to the handler for processing, and a new ACT (Abstract Composition Tree) is instantiated, ready to construct and compose any return message. Again, the prototype performs no optimization; these actions occur each time an interaction is initiated by a client, with the exception of translator generation, which need be performed only once per version of a protocol. Many optimizations and parameterizations are again possible, though they are left for future implementations. 6.6. Errors The discussions presented by the last two sections introduce the possibility for several points at which errors can occur. We will categorize the errors that might occur as those that can occur during the generation of a translator and those that can occur during the process of event-based translation. 6.6.1. Errors of Generation Figure 59 and Figure 60 detail the artifacts used to construct the elements of the event-based translation system; essentially, the former diagram shows the “development-time” half of this construction and the latter diagram shows the “runtime” half of this construction. 195 For the event-based translation system to function at all, the static process must be correct. Although errors can (and certainly did) occur during development, we will assume a valid negotiator is the output of this half of the construction effort. All of the first-level inputs (i.e., those data elements that are not the output of a process, viz., the JavaCC specification files of the specification parsers, and the negotiator, generator, and various other Java source files) were controlled by the prototype developer and are considered to be correct for the purpose of evaluating the dynamic process. Prior to the translation of messages and concept events, the latter half of the construction process relies on a single, first-level input (viz., a protocol specification). This specification is not controlled by the prototype developer, but is instead controlled by the protocol/application developer. The prototype developer cannot thus guarantee that any given protocol specification is correct. The processing of such can produce errors at several points along the process of instantiating a translator. The first errors can occur while the specification parsers of the negotiator are reading the protocol specification. Since a protocol specification is provided piecemeal by small files that reference one another, an entire protocol specification is first read by the negotiator’s generator into a single data structure, prior to being operated upon. Syntactic errors within the protocol specification will be detected at this point, and can be easily reported. After the full specification is read, references within the data structure are resolved. During this phase, some semantic errors of protocol specification are 196 detected (e.g., a production referencing another, nonexistent production). This is the second level of errors that will be detected. Once some elementary semantic analysis has been performed, the internal data structure that represents the protocol specification is written out to a JavaCC specification file, which is used as input to the JavaCC utility. Here, the third level of errors will be detected by the compiler compiler, as it performs its analysis of the parser specification file to ensure an LL(1) specification (e.g., unique left prefixes, etc.). Note that the syntax of the parser specification file should be correct, given that it was generated by the event-based translation system. The remainder of the translator generation should be free of further errors, given that the generated artifacts are correct not only in terms of Java syntax but also with respect to the restrictions imposed by the event-based translation system. Consequently, the execution of the Java compiler (to compile the translator) and the Java Virtual Machine (to execute the translator) should occur normally. An error at this point indicates a problem not with the generated source but with the component and/or process by which that source was generated (i.e., the negotiator’s generator). 6.6.2. Errors of Translation Once a translator has been generated and instantiated, it can receive/send protocol messages and receive/send protocol concept events. Although the outgoing data is controlled, the incoming data is not and is thus another possible source of errors, albeit errors of translation. Presuming that a corresponding composer of a translator for the appropriate protocol and version is responsible for composing any incoming messages (i.e., 197 incoming messages are composed by a remote instance of the event-based translation system), a translator’s parser should not encounter an error during the parsing of a message. If, however, the message comes from an independent application without the intermediary of a translator (or was improperly composed, see below), it may not conform to the specification the application purports to implement. In this case (for the prototype), the parse will merely fail and the interaction will terminate abnormally. Events handed to a translator for message composition can also be erroneous, or at least inconsistent. These inconsistencies can be defined away by the specification of the ACT construction activity, however (q.v., Section 5.3.5). The prototype conforms to the default composition variants, which simply ignore the possibility of inconsistency and are thus capable of producing erroneous messages under unusual circumstance of conflicting input.